1. Field of the Invention
The present invention generally relates to collaboration systems implemented on networked computers and, more particularly, to a distributed server that substitutes for a centralized server in real-time collaboration sessions.
2. Background Description
Software for collaborative work, i.e., work involving many users and/or agents falls into two categories of use. One is termed asynchronous collaboration and the other, synchronous collaboration. Examples of software for asynchronous collaboration are groupware such as Lotus Notes and Microsoft Exchange. These along with other examples such as discussion groups where data is changed batchwise have the characteristic that neither do they require, nor do they particularly cater to the concurrent presence of many users and agents in the work environment. The work environment can include all users and agents that use computers that are connected to each other by networks such as the Internet or intranets. In contrast to software for asynchronous collaboration, software for synchronous collaboration is designed to cater to concurrent users and agents. It includes collaboration tools such as chat, concurrent whiteboards and the more sophisticated SameTime environment. These tools provide for real-time interaction among groups using the same shared workspace. Whatever be the work space--document, spreadsheet, CAD drawing, etc.--it can be seen and modified by the collaborators, simultaneously. Modifications to the work space are made available to all group members, immediately and synchronously.
Synchrony in multiple updates made by collaboration participants has to be ensured by the underlying synchronous collaboration implementation. One of the common ways by which this is done currently is by the inclusion of a centralized server. A centralized server is a software process running on one host machine, a computer or computing element, that introduces a serialization order among multiple, concurrent modifications. Thus multiple, simultaneous updates to a shared work space are communicated to the server which converts them into a sequential stream of updates to the work space. The sequential stream of updates is then reflected back to all participants, each of whom is assumed to be running a software process, a client, in order to interact with the work space. Each participant or client thus sees the shared work space develop in an identical manner--basically starting from the same initial state and changing under the same stream of updates--as any other participant or client of the collaboration. This method of streaming updates is parameterised by the definition of a modification. What is a modification? Is it a sequence of user-level operations and/or some translation of the same? Is it the complete, changed work space itself? Is it an object difference--changed work space minus unchanged work space? What is the role of history of serialization in serialization itself? Is there any role? Answers to each of these questions can affect what the collaboration session means to its users and also cause a different implementation of synchronous collaboration. Yet what all of these implementations have in common is their dependence on one server process to make serialization decisions for them. As collaboration needs scale up (e.g., the number of clients changing the work space, the number of changes to the work space, and the number of synchronous views of the work space goes up) the single server process running on a single machine and the interconnection network bringing about communication between the server and the clients can become severely loaded with computation and communication requirements. Indeed since the architecture of the collaboration implementation is such that it focuses all communication to one point in the interconnection network, namely the server's machine, the development of an unbalanced load in the interconnection network takes place. It is possible that the interconnection network cannot effectively service the "hot spot" of communication, viz. the server's machine, despite being relatively lightly loaded in other parts of the network. The result can be unacceptable delays and degradation in performance from the perspective of collaboration participants.